It is known that wireless communications such as radio communications need to be secured by encryption owing to the relative ease with which wireless communication can be compromised. (The term “wireless” as used herein is intended to include any communication in which electromagnetic waves (rather than some form of wire) carry a signal over part or the entire communication path. Examples of the invention will be described with reference to radio communication, which uses radio-frequency electromagnetic waves to carry the communication and which is one example of wireless communication, but the invention is not limited to radio communication.) For this purpose, a wireless communication is usually secured using a cryptographic method based on one or more keys that are known to (or are “shared” by) the wireless network, or at least the originating and terminating terminals between which the wireless communication is being sent. In one known technique two keys, a “ciphering key” and an “integrity key”, are used as basis for information/data confidentiality and integrity/authenticity.
In many cases, security is defined over a wireless link such as a radio link. In the case of communication between a mobile terminal (such as a mobile telephone) and a fixed base station, this means that the mobile terminal and the base station BS (or “access point” AP) are termination points for security, and thus need access to the key(s) used to secure the communication. However, distributing a key to multiple and easily accessible nodes poses a threat, as it increases the opportunities for an attacker to obtain a key.
This has not been a problem in WCDMA (Wideband Code Division Multiple Access, a standard used in 3G mobile telecommunication networks), since the security terminates in the Radio Network Controller (RNC) which sits in a relatively well protected site. However, in the LTE (“Long Term Evolution”) mobile telecommunication standard, termination of radio link protection has been moved down to the base station (called “eNB” in LTE) which is much more exposed. In addition, new 3G evolution/HSPA (High Speed Packet Access) architectures allow the RNC functionality (or parts thereof, e.g. ciphering) to be moved to the base station (which is called “NodeB” in WCDMA). This means that it is necessary to protect the key(s) stored and used in the base station. One way of doing this is by improving the ways in which keys are managed.
The LTE standard includes a feature whereby the keys are changed at every intra-LTE handover. Thus, if “KeNB1 ” denotes a key used to protect wireless traffic 4 between a mobile terminal (also referred to as Mobile Equipment (ME)) 1 and a first base station 2 (eNB1) in FIG. 1, then, after handover (or handoff) of the ME to a new base station 3 (eNB2), the new base station 3 will not use the original key KeNB1 for communication with the ME 1. Instead, the new base station 3 will, after a handover, use a new key KeNB2 that is derived from the original key KeNB1, for example where KeNB2=f(KeNB1, eNB2_ID), where eNB2_ID is an identifier associated with the new base station 3. The application of a function f to a key will hereinafter be referred to as “tweaking” the key. The function f is a key derivation function, typically based on a suitable cryptographic function, e.g. a (presumed) one-way function or a pseudo-random function. If more than one key needs to be tweaked this can easily be accomplished by using a set of functions F, where fi is applied to obtain the ith key, for fi in F.
The key KeNB2 is calculated by the first base station 2 and is transferred from the first base station 2 to the new base station 3 via a communication channel (e.g. the X2 interface) that connects the two base stations. Since the ME 1 is aware of the function f, the ME 1 can also derive the new key KeNB2 by performing the same calculations locally (the ME only needs knowledge of KeNB1 and the identity of eNB2, which are both available). Thus, after handover wireless communications 5 between the new base station 3 and the ME are protected using the new key KeNB2 rather than using the original key KeNB1.
This means that even if someone is able to extract the new key KeNB2 from the new base station 3 then, provided the function f is correctly chosen, the original key KeNB1 is still “safe” in the sense that it cannot be deduced from the information retrieved by extracting the key KeNB2. Hence an intruder cannot record encrypted traffic between the first base station 2 and the mobile terminal 1, obtain the key after the ME has been handed over to the new base station 3 (which is assumed to be compromised) and then use the key to decipher traffic to/from the first base station 2.
It should be noted that in LTE there are also other mechanisms for changing keys at relocation (and in conjunction with certain state-changes of the ME). However, these mechanisms all require that the new key is generated by another network node, the so-called Mobility Management Entity (MME), and will therefore not be discussed further.
It will be understood that it is desirable that the computation of the new key KeNB2 is done in the first base station 2, as otherwise the original key KeNB1 would, at least temporarily, be exposed also in the new base station 3.
Current WCDMA networks have no possibility to change keys, except by running an authentication and key agreement (AKA) procedure which imposes signalling delays and induces load on the AuC/HLR (authentication centre/home location register), the RNC, the MSC (Mobile Switching Centre) and other nodes.
There is a current work item in 3GPP to study key management enhancements for UTRAN (TS 33.102, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security architecture, http://www.3gpp.org/ftp/Specs/archive/33 series/33.102/33102-910.zip), i.e. for the WCDMA-based access network. It is within the scope to look at a solution to the problem of changing the keys at handover. However, as of now, little to no discussion on solutions has occurred and so far, the study has only discussed how to change the keys when they are transferred from the core network (VLR/MSC/SGSN) to the RNC, e.g., at initial attach or at Routing Area Update (RAU). This problem, of a “vertical” key change between a Core Network (CN) and a Radio Access Network (RAN) is a much simpler problem than the problem of a “horizontal” key change within a RAN, and has a solution that should be largely independent of a solution to the “horizontal” key change within a RAN. It has been acknowledged that it should be possible to change the keys also at SRNS relocation (i.e. when the ME changes its serving RNC), but exactly how that would be achieved is still open (see S3-100319, 3GPP TR 33.ukh V0.3.0 (2010-02).
Reviewing the different cases of mobility/handover defined in the existing 3GPP specifications there can be identified three cases of “horizontal” key derivations which need to be considered for any fully specified solution. These cases coincide with the mobility events that causes a change of RNC: SRNS (Serving Radio Network Subsystem) relocation without ME involvement (see 6.9.2.2.1 of TS 23.060, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS); Service description; Stage 2, http://www.3gpp.org/ftp/Specs/archive/23 series/23.060/23060-930.zip), combined hard handover and SRNS relocation (see 6.9.2.2.2 of TS 23.060) and combined cell/URA update and SRNS relocation (see 6.9.2.2.3 of TS 23.060). In comparison, in the LTE standard the only case that exists is the one corresponding to combined hard handover and SRNS relocation. In other words, the existing LTE solution cannot be adopted in UTRAN in any straight-forward manner since it does not cover all cases. In addition the problem of interoperability with legacy terminals and network equipment does not exist in LTE since it was designed from the beginning to support the above-described key-change mechanism. The issues with introducing such a key-change mechanism in networks that are already deployed, but which do not have this functionality, will be apparent from the further discussion below.
When performing SRNS relocation without ME involvement, the network changes the serving RNC from the source RNC (the “source RNC” is the currently serving RNC) to the target RNC (which is a currently drifting RNC) even though the ME remains connected to the same base station (NodeB). This is illustrated in FIG. 2(a), which shows two RNCs 6a (or RNC1), 6b (or RNC2) connected to a core network 7. Each Base station is controlled by one RNC—FIG. 2(a) shows, as an example, two base stations, 8a (NodeB1) and 8b (NodeB2), controlled by RNC1 and one base station, 8c (NodeB3), controlled by RNC2. An ME 1 is served by one RNC, for example with RNC1, via a base station (NodeB1) before SRNS relocation. After SRNS relocation the ME is, as shown in broken lines, served by another RNC, for example with RNC2, via the same base station as before SRNS relocation. Only at the end of the SRNS relocation without ME involvement procedure, the target RNC (in this example RNC2 is the target RNC) informs the ME about the change of serving RNC. Hence, the ME is unaware of the change of RNC until it is completed, and this makes it difficult for the ME to determine which keys were used to protect certain messages (to be described in more detail later)—any solution adopted for UTRAN must overcome this problem.
In the combined hard handover with SRNS relocation case, the ME is informed by the source RNC that it shall change base station and at the same time it is to be served by a target RNC. This is illustrated in FIG. 2(b), which shows two RNCs connected to a core network. Before SRNS relocation an ME 1 is served by one RNC via a base station, for example with RNC1 via base station NodeB1. After SRNS relocation the ME is, as shown in broken lines, served by another RNC, for example RNC2, via a different base station (e.g., base station NodeB3) than before SRNS relocation.
In the combined cell/URA with SRNS relocation update case, the ME realises that it has moved into a new cell and sends an update message to the source RNC. This is illustrated in FIG. 2(c), which shows two RNCs connected to a core network. Note that FIG. 2(c) is identical to FIG. 2(b), but the signalling sequences differ. Before relocation an ME 1 is served by one RNC via a base station (for example is served by RNC1 via base station NodeB1). After relocation the ME 1 is, as shown in broken lines, served by another base station, which may be a base station served by the same RNC as the base station before relocation (eg NodeB2) or which may alternatively be a base station served by a different RNC to the base station before relocation (e.g., NodeB3 which is served by RNC2 and not with RNC1). The network decides if the update is acceptable and if so changes the serving RNC to the target RNC (if necessary) and the target RNC then informs the ME about the change of RNC. Again, the ME is informed of the change of RNC only at the end of the procedure.
During SRNS relocation, the source and target RNC communicate with each other via the core network to coordinate the relocation. In later versions of the UTRAN standard, there is also a procedure called enhanced SRNS relocation where the RNCs communicate directly with each other via the lur interface as shown schematically in FIGS. 2(a) to 2(c).
The existing approaches for providing key tweaking, independently on the ME and the network sides, have a number of problems in the procedures discussed above. For example as mentioned, new 3G evolution/HSPA architectures allow the RNC to be collocated with the NodeB (possibly in the same hardware chassis). This implies that ciphering and integrity protection is performed in a location which is in the periphery of the network (possibly the radio equipment chassis is located in a hostile environment where hackers may physically attack it to get access to the ciphering keys). This makes it necessary to investigate enhanced protection of the keys used in HSPA. In particular, it would be beneficial to change keys when the RNC is changed at SRNS Relocation. Unlike the LTE standard however, the system was not designed from the outset to take the need to change keys at relocation into account. If a feature of changing keys at relocation is introduced, we need to provide for                backwards compatibility when interworking with legacy equipment.        backwards compatibility with the existing signalling, changing as little as possible of the existing procedures.        
It should be noted that neither WiMAX (IEEE 802.16) nor WLAN (IEEE 802.11) include a standardized way to change key at inter-BS/inter-AP handovers as an integral part of the handover procedure. Rather, the only possibility to change keys at handover for these radio access technologies is based on a performing a full (or in the WLAN case, the optimized 802.11r) authentication between the terminal (STA) and the target BS/AP. This is not acceptable in WCDMA as zero signalling overhead is desired (from key management point of view; there will of course be mobility signalling taking place).